
 
IBM DIALS SWITCH 4.5.3p2 PATCH RELEASE NOTES 

CALL-BY-CALL FEATURE SUPPORTED 
Solution:
Release 4.5.3p2 contains the parameter CallFeature=X (where X= the HEX NFS
value given to you by your telephone company).  The NFS value is placed in the
setup message to the Telco in the NFS field. The NFS value routes voice
outbound calls from the IBM Dials Switch.
To implement the Call-by-Call feature, add the following parameters in the
Additional Configuration page in the Management Facility:

[WANInterfaceX]
CallFeature=0x04 (hex)

NOTE: Generally, a hex value should be used, although you may need to enter a
binary value, depending on how the Central Office switch is configured.  If
your telephone company representative does not know whether the NFS value is
binary or hex ask them to find out. If they are unsure, try it both ways. Also,
you can enter the decimal value and the system will convert the value to hex in
the NFS field.

COMMAND SHELL TO  PPP TRANSITION MAY CAUSE CRASH
  After connecting to the shell, your dial-in client initiates PPP.
Problem:
The transition from shell to PPP may cause the LRAS to crash.
If you are experiencing this problem, you will see the following messages in
the log:
reason: PLX <followed by numbers>
process: DMC driver
Solution:
The 4.5.3p2 firmware patch has eliminated this problem.

DIAL-OUT AND DIAL-BACK Problems With LRAS and T1 Robbed Bit Loop Start Signaling
Problem:
Dial-out and dial-back did not work on systems configured for T1 Robbed Bit and
Loop Start signaling.
Solution:
The 4.5.3p2 firmware patch has eliminated this problem.

DIAL-OUT SESSION CAUSES T1 CHANNEL TO REMAIN IN RESERVED STATE
Problem:
Clearing dial-out sessions over T1 Robbed Bit lines caused timeslots to remain
in the Reserved state.
Timeslots that are in a Reserved state cannot be used for dial-in or dial-out.
Eventually, all timeslots become inoperable and all users are prevented from
dialing in or dialing out The unit must be reset to clear the problem.
To verify that timeslots are in the Reserved state, enter the following
commands from the command shell:
show stat line <slot_#>  <line_#>
show calls
Solution:
The 4.5.3p2 firmware patch has eliminated this problem.

MEMORY LEAKS in LRAS 4.5
Problem:
Users with the above configuration experienced an abnormal loss of memory in
the box, resulting in a system crash.
To determine whether your system is leaking memory, enter the sho ver command
from the command shell. If the volatile memory available is below 500k, your
system may crash or the following could occur:
  All dial-in users receive a fast busy.
  Users cannot  telnet into the box (the session is immediately dropped after
authentication).
  The LRAS Activity Log contains the following error message: "Fail to Create
Process X" (where X is the name of the process, for example, the Authentication
Process).
Solution:
The 4.5.3p2 firmware patch has eliminated the following memory leaks:
  LCP negotiation leak. Any LCP configuration ACK sent or received after the
first one was lost.  PPP clients that failed LCP negotiation and had to
renegotiate LCP leaked more memory than the 8235 Server or clients that did not
fail LCP negotiation.
  Several Layer Two Forwarding memory leaks. Specifically, a buffer leak
occurred when authenticating via CHAP over L2F.
  ARA dial-in leaks.  Buffers routed to the serial interface were not cleared
correctly.

DIAL DELAY PARAMETER for LRAS DIALBACK on ISDN
Problem:
The IBM DIALS SWITCH called the dial-in client before the TA had time to
reinitialize.
Solution:
The Dial Delay parameter is configurable in the 4.5.3p2 code. Enter the
following information in the Additional Configuration page in the Management Facility:

PhoneGroupX]
DialDelay= 2

The default for DialDelay is 0. You must change this value to 2 if you use the
dial-back feature with ISDN.
If using Loop Start signaling, the following parameters should also be set:

[WANInterfaceX]
DialOutPause=2
TimedAnswer=1

IBM DIALS SWITCH  LOSES IPX ROUTING INFORMATION WHEN VIRTUAL CONNECTION IS 		
LOST.
Problem:
If the IBM DIALS SWITCH lost its virtual connection information for an
AccessPort that had been connected to it (for example if the LRAS was restarted
or the suspended VC timed out) and the AccessPort was not restarted,  when the
AccessPort resumed its suspended virtual connection to the LRAS, the IPX
routing information was not propagated correctly.
When this occurred, users were unable to access any IPX network services.
Solution:
The 4.5.3p2 firmware patch has eliminated this problem.

MODEMS ADMINISTRATIVELY DISABLED BY ACCESS SWITCH WITHOUT USER INTERVENTION
Problem:
Modems on the DMC for the IBM DIALS SWITCH were erroneously marked as
Administratively Disabled by the IBM DIALS Switch.  Consequently, these
modems would be taken out of the modem resource pool.
The following symptoms occurred:
  Users received busy signals if enough modems became Administratively
Disabled.
  The log recorded rejected calls.
  Modems were marked as Administratively Disabled when the show resource modem
shell command was executed.
  Each disabled modem generated the following log message:  DMC(8): ErrorMsg,
reason: operation in progress (opcode = 0x8010).
  This message may still appear with the patch, but the modem will no longer be
disabled.
Solution:
The 4.5.3p2 firmware patch has eliminated this problem.

DEFAULT TELNET BUFFER SIZE TOO SMALL
Problem:
User input for a telnet session from the shell was limited to 50 characters.
This limit was reasonable for a user typing at a terminal, but the limit was
easily exceeded if an application was sending data (for example, a shell
script).
Solution:
The default telnet buffer size for the 4.5.3p2 release is 2048.


MLP CONNECTION FAILS IF WRONG USER NAME IS ENTERED
Problem:
Previously, if a user dialed in from an ISDN client using MLP and the user
typed in an incorrect user name, the invalid user name was erroneously saved in
the data structure associated with the MLP bundle. Subsequently, when the user
entered a valid user name, and the valid user name was authenticated, the
firmware could not bring up the second link in the multilink bundle.
The following symptoms occurred:
  The second B-channel would not come up.
  The second B-channel would come up, but network services were not available.
  The dial-in client could not authenticate even after the correct user name
was entered. The only way to resolve this problem was to reboot the PC.
Solution:
The 4.5.3p2 firmware patch has eliminated this problem.


ClearUnaccountableCalls PAREAMETER DISABLED BY DEFAULT
Problem:
The ClearUnaccountableCalls feature when enabled will collect call data that
would normally go to a RADIUS server in the event that the RADIUS server goes
down. The maximum amount of call data that the LRAS can collect is 256K. If
this limit is reached, the LRAS will stop taking calls.
This feature is useful if you have a need for this call data.
Many users do not want the LRAS to stop taking calls if the call cannot be
accounted.
Solution:
Because this feature shuts down the LRAS when it reaches the 256K limit, the
default for the 4.5.3p2 release will be to have it disabled.
In the 4.5.3p2 release, you have the option to turn this feature on by adding
the following parameters in the Additonal Configuration page in the Manage-
ment Facility:

[Accounting]
ClearUnaccountableCalls=1

MaxDRAM=256  {USE NO MORE THAN 256K FOR ACCOUNTING RECORDS}
New Upline Load Parameter
Problem:
The LRAS would time out before sending an upline load to the TFTP server.
Solution:
The maximum amount of time the LRAS will attempt to send data to the upline
host is now configurable in release 4.5.3p2. Add the following parameters to
the Additional Configuration page in the Management Facility:

[Upload]
MaxTryMinutes=5


DMC Modem Initialization Failure On Call Startup
Problem:
DMC modem initialization failure occurred on call startup.
Analog calls to the LRAS did not complete normally and, as a result, modem
resources became disabled.
The following symptoms occurred:
  The modem could not take calls.
  When issuing the dmc state command in the command shell, the modem showed a
status of MODEM_INITD.
Solution:
The 4.5.3p2 release adds a 6-second timer to clean up if the process was not
completed successfully.
